src/libraries/ai.tsx (1)

16-49: ⚖️ Poor tradeoff

Consider consolidating overlapping feature content.

The featureHighlights array here partially overlaps with the 8 hardcoded feature cards in AiLanding.tsx (lines 64-121). Topics like "Provider Agnostic," "AG-UI Native," and "Typed Tools" appear in both locations with similar but not identical wording. This duplication creates a maintenance burden if the messaging needs to stay synchronized or evolve together.

Consider whether the two sections could reference a single source of truth, or document the intended distinction between the LibraryFeatureHighlights section and the ecosystem grid cards.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/libraries/ai.tsx` around lines 16 - 49, The featureHighlights array in
src/libraries/ai.tsx duplicates messaging found in the hardcoded feature cards
in AiLanding.tsx; extract the shared feature data into a single exported
constant (e.g., export const LIBRARY_FEATURES) and have both
LibraryFeatureHighlights (featureHighlights) and the AiLanding card grid import
and use that constant, or alternatively add brief comments/descriptions to each
source to document the intended distinction if they must remain different;
update references in the component that currently uses featureHighlights and in
AiLanding.tsx to consume the new shared symbol so messaging is maintained in one
place.

src/components/landing/AiLanding.tsx (1)

66-70: 💤 Low value

Consider mentioning Vanilla framework.

The stack context indicates Vanilla is a supported framework alongside React, Vue, Solid, Svelte, and Preact, but it's not mentioned in the "Client Agnostic" card or elsewhere in the marketing copy. Verify whether Vanilla should be included or if its omission is intentional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/landing/AiLanding.tsx` around lines 66 - 70, The marketing
copy in the AiLanding component’s "Client Agnostic" card omits "Vanilla" from
the list of supported frameworks; update the paragraph text in the AiLanding
component (the <h4> with "Client Agnostic" and its following <p>) to include
"Vanilla" alongside React, Vue, Solid, Svelte, and Preact (e.g., "React, Vue,
Solid, Svelte, Preact, and Vanilla") or, if omission was intentional, add a
brief comment in the AiLanding component explaining why Vanilla is excluded so
reviewers know it’s deliberate.

src/components/AILibraryHero.tsx (1)

243-278: 💤 Low value

pulse-down and pulse-up keyframes are identical—direction has no visual effect.

Both keyframe definitions at lines 243–256 and 257–270 produce the same animation. If the intent is to visually differentiate the pulse direction (e.g., gradient offset, translateY, or brightness sweep direction), the keyframes need distinct definitions. Otherwise, connectionPulseDirection toggling at line 185 is effectively dead logic.

If both directions should look the same, consider consolidating into a single pulse animation to reduce duplication.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/AILibraryHero.tsx` around lines 243 - 278, The two keyframes
pulse-down and pulse-up are identical so toggling connectionPulseDirection has
no effect; either make the animations visually different (e.g., change
transform/translateY, gradient offset, or staggered filter/brightness values in
pulse-down vs pulse-up) and keep both keyframes and the classes
(.animate-pulse-down, .animate-pulse-up), or consolidate them into a single
pulse keyframe and replace usages of pulse-down/pulse-up (and the
connectionPulseDirection toggle) with that single animation to remove dead
logic; update the animate-pulse-* class definitions and any code referencing
connectionPulseDirection accordingly.

src/hooks/useAILibraryHeroAnimation.ts (1)

181-210: 💤 Low value

Service rotation duplicates runRotation logic.

The custom service rotation loop (lines 185-207) largely duplicates the runRotation helper with different timing constants. Consider parameterizing runRotation to accept timing configuration, which would reduce duplication and ensure consistent behavior.

That said, the current implementation is functionally correct and the timing differences are intentional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/hooks/useAILibraryHeroAnimation.ts` around lines 181 - 210, The
rotateService function duplicates runRotation logic; refactor by adding
parameters to runRotation (e.g., startIndex, rotations, timingConfig,
targetService, onComplete) and reuse it instead of rotateService: call
runRotation(currentServiceIndex, serviceRotations, {fast:
TIMING.serviceRotationFast, slowBase: TIMING.serviceRotationSlowBase, slowInc:
TIMING.serviceRotationSlowIncrement}, targetService, onComplete) so addTimeout,
store.setRotatingService, index incrementing, final selection behavior and
TIMING-based delay computation live in runRotation and the current rotateService
block is removed; keep references to SERVICES_COUNT, SERVICE_WIDTH,
SERVICE_GUTTER, addTimeout and store.* calls inside runRotation to preserve
behavior.

src/components/AILibraryHero.tsx (1)

502-502: 💤 Low value

Magic numbers in path control points.

The Bezier curve control point Y-coordinates (322 and 424) are hardcoded. Consider deriving these from existing layout constants (e.g., based on SERVER_CARD_Y_OFFSET and SERVICE_Y_OFFSET) for maintainability if the layout geometry changes again.

+const SERVER_TO_TANSTACK_CONTROL_Y = (TANSTACK_AI_BOX.y + TANSTACK_AI_BOX.height + SERVER_CARD_Y_OFFSET) / 2
+const SERVER_TO_PROVIDER_CONTROL_Y = (SERVER_CARD_Y_OFFSET + SERVER_CARD_HEIGHT + SERVICE_Y_OFFSET) / 2

Also applies to: 522-522

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/AILibraryHero.tsx` at line 502, The Bezier path strings use
hardcoded control Y values (e.g., the `d` attribute building string in
AILibraryHero that contains `Q ${serverBoxCenterX} 322 ${endX}
${SERVER_CARD_Y_OFFSET}` and the similar instance around line 522); replace
those magic numbers with computed values derived from existing layout constants
(for example compute controlY as a function of TANSTACK_AI_BOX.y,
TANSTACK_AI_BOX.height, SERVER_CARD_Y_OFFSET, and SERVICE_Y_OFFSET or an
average/midpoint between the source and target Y positions) and use that
computed variable in the template literal so control points adapt when
SERVER_CARD_Y_OFFSET or SERVICE_Y_OFFSET changes.

src/utils/documents.server.ts (1)

129-135: ⚡ Quick win

Consider adding a documentation comment.

The ../../.. navigation assumes a specific directory structure (sibling repositories in local development). A brief comment explaining the path resolution would help future maintainers.

📝 Suggested documentation

+/**
+ * Resolve the base directory for a local repository.
+ * Assumes repos are siblings to the main project:
+ *   parent/tanstack.com/src/utils/documents.server.ts (this file)
+ *   parent/{repo}/ (target repo)
+ */
 function getLocalRepoBaseDir(repo: string) {
   return path.resolve(
     path.dirname(fileURLToPath(import.meta.url)),
     '../../..',
     repo,
   )
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/utils/documents.server.ts` around lines 129 - 135, Add a brief
documentation comment above the getLocalRepoBaseDir function explaining that it
resolves a local sibling repository path by walking up three directories via
'../../..' from the current file (fileURLToPath(import.meta.url)) and that this
assumes the monorepo/project layout used in local development; mention expected
repo layout and a caution that changing project structure requires updating this
relative path. Ensure the comment references getLocalRepoBaseDir and the
'../../..' segment so future maintainers understand the assumption and where to
update if layout changes.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/components/landing/AiLanding.tsx (1)

60-64: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix subject-verb agreement.

The sentence has a grammatical error: the singular verb "is" doesn't agree with the plural compound subject "libraries and standards."

✏️ Proposed fix

-            TanStack AI is open-source libraries and AG-UI-compatible standards,
+            TanStack AI provides open-source libraries and AG-UI-compatible standards,

Alternatively:

-            TanStack AI is open-source libraries and AG-UI-compatible standards,
+            TanStack AI is a set of open-source libraries and AG-UI-compatible standards,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/landing/AiLanding.tsx` around lines 60 - 64, In the AiLanding
component update the sentence so subject and verb agree: change "TanStack AI is
open-source libraries and AG-UI-compatible standards" to use a plural verb or
rephrase (e.g., "TanStack AI are open-source libraries and AG-UI-compatible
standards" or better "TanStack AI comprises open-source libraries and
AG-UI-compatible standards")—edit the string in the AiLanding component where
that paragraph is defined to use the corrected wording.

src/libraries/frameworkSupport.ts (1)

3-23: ⚡ Quick win

Remove libraryId from helper input to avoid split-source mismatches.

getFrameworkPackageName can derive everything from library.id; taking both libraryId and library makes incorrect pairings possible and can silently produce wrong package names.

♻️ Suggested change

 export function getFrameworkPackageName(
   framework: Framework,
-  libraryId: LibraryId,
   library: LibrarySlim,
 ) {
   const packageName = library.frameworkPackageNames?.[framework]

   if (packageName) {
     return packageName
   }

   if (framework === 'vanilla') {
-    return library.corePackageName ?? `@tanstack/${libraryId}`
+    return library.corePackageName ?? `@tanstack/${library.id}`
   }

-  if (framework === 'angular' && libraryId === 'query') {
+  if (framework === 'angular' && library.id === 'query') {
     return '`@tanstack/angular-query-experimental`'
   }

-  return `@tanstack/${framework}-${libraryId}`
+  return `@tanstack/${framework}-${library.id}`
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/libraries/frameworkSupport.ts` around lines 3 - 23, The helper
getFrameworkPackageName currently accepts both libraryId and library which
allows mismatched pairs; change its signature to only accept (framework:
Framework, library: LibrarySlim) and derive the id from library.id everywhere
inside the function (use library.id in place of the former libraryId variable)
while preserving the existing special-casing for 'vanilla' and the angular query
exception; then update all call sites that passed a separate libraryId to pass
only the library and framework (or extract library.id at the call site) so
callers match the new signature and no longer risk inconsistent
libraryId/library pairs.

tests/ai-framework-doc-links.test.ts (1)

27-54: 🏗️ Heavy lift

Add an existence check for each docs path, not just string equality.

This test currently verifies configured mappings but doesn’t verify that each resolved docs path actually exists, so 404 regressions can still slip through while this test passes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/ai-framework-doc-links.test.ts` around lines 27 - 54, The test only
compares configured strings (expectedDocsPaths) but doesn't assert those docs
paths actually exist; update the loop that iterates expectedFrameworks to, after
computing docsPath = getFrameworkDocsPath(framework, ai), resolve that logical
docs path to the repo docs file (e.g. join process.cwd() with the docs root and
check for either `${docsPath}.md` or `${docsPath}/index.md`) and add an
assertion like assert.ok(fs.existsSync(resolvedPath), `Docs page for
${framework} exists`); you can encapsulate the filesystem check in a small
helper (e.g. docsPathExists or resolveDocsFile) to keep the test readable and
use Node's fs and path modules.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tests/ai-framework-doc-links.test.ts (1)

4-7: ⚡ Quick win

Add coverage for getFrameworkDocsHash to lock full link behavior.

FrameworkCard now depends on docs path + hash together. Extending this test to assert hash behavior will prevent regressions where links resolve to wrong anchors.

Proposed test extension

 import {
+  getFrameworkDocsHash,
   getFrameworkDocsPath,
   getFrameworkPackageName,
 } from '../src/libraries/frameworkSupport'

+const expectedDocsHashes: Partial<Record<Framework, string | undefined>> = {
+  react: undefined,
+  vue: undefined,
+  solid: undefined,
+  svelte: undefined,
+  preact: undefined,
+  vanilla: undefined,
+}
+
 for (const framework of expectedFrameworks) {
   assert.equal(
     getFrameworkPackageName(framework, ai.id, ai),
     expectedPackages[framework],
     `${framework} package name points to the shipped AI package`,
   )

   assert.equal(
     getFrameworkDocsPath(framework, ai),
     expectedDocsPaths[framework],
     `${framework} framework card links to an existing AI docs page`,
   )
+
+  assert.equal(
+    getFrameworkDocsHash(framework, ai),
+    expectedDocsHashes[framework],
+    `${framework} docs hash matches framework-link contract`,
+  )
 }

Also applies to: 42-54

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/ai-framework-doc-links.test.ts` around lines 4 - 7, Extend the existing
test to call getFrameworkDocsHash in addition to getFrameworkDocsPath and
getFrameworkPackageName and assert that FrameworkCard-style links are built
using the docs path concatenated with the returned hash (i.e., verify
`${getFrameworkDocsPath(...) }#${ getFrameworkDocsHash(...) }` or equivalent is
produced); update the test to cover multiple frameworks (reuse existing test
inputs) and add assertions that the final link equals the expected path+hash
string so both path and hash behavior are locked down (refer to functions
getFrameworkDocsHash, getFrameworkDocsPath, getFrameworkPackageName and the
FrameworkCard link behavior).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes